home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16102 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.2 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 08:25:27 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kdvh7INNdjb@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.829011320@schonberg> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> <dewar.829051685@schonberg>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <dewar.829051685@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  12. >Kazimir said:
  13. >
  14. >>This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a
  15. >>pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and
  16. >>until now I have been completely oblivious to this difference between Linux
  17. >>and other systems.
  18. >
  19. >  The spec of an interface does not depend on what "wouldn't even occur"
  20. >  to Kazimir, it must be independently defined.
  21.  
  22. I totally agree. But in the absence of the definition, we have to stick with
  23. the safer thing.
  24.  
  25. >>Unfortunately, I could not find anything in POSIX.1 that would explicitly
  26. >>disallow this. The document is not very assertive in defining undefined
  27. >>behavior. I'm going to check it once again in case I missed something.
  28. >
  29. >  This is not a matter of defining undefined, it is a matter of defining
  30. >  the requirement on the length of the read buffer, and it is truly
  31. >  amazing to me that none of the references at hand, not even the POSIX
  32. >  document, specifies this.
  33.  
  34. I might come up with something up if I read the damn thing character by
  35. character, cover to cover. But I did spend a fair bit of time chasing around
  36. the document, in vain.
  37.  
  38. >>It's not surprising: you lied to the read() function. But you are right, you
  39. >>can't tell this from the definition in POSIX.1 or from typical manual pages.
  40. > 
  41. >  Sorry, this is wrong, I lied to the *implemention* of the function as
  42. >  it occurred in Linux. Now it is true that the spec of the function is
  43. >  different in Linux than in other systems (you quoted the manual pages
  44. >  that showed this clearly). So of course we have a portability problem
  45. >  here. Read is different in different systems, not only at the
  46. >  implementation level, but at the spec level. The program in question
  47. >  was correct with respect to the spec on "other systems":
  48. >
  49. >>I checked the manual pages for read() on several systems. Linux documents
  50. >>that results if the buffer pointed at by buf is outside of the address space
  51. >>of the process. On other systems, it is claimed that EFAULT results if
  52. >>the buf pointer is directed outside of the address space.
  53. >
  54. >  Kazimir, perhaps you don't understand the whole idea of specs, but that
  55. >  quote means that code that makes sure that the pointer is directed inside
  56. >  the address space is OK if the buffer is not overrun!
  57.  
  58. Right. The distinction is quite clear. The Linux doc talks about the whole
  59. buffer object, whereas the SunOS and HP-UX man pages talk about the buffer
  60. pointer.
  61.  
  62. >>There are certain unwritten rules, though!
  63. >
  64. >  That's the totally unacceptable viewpoint that is at the center of
  65. >  the concerns in this thread (the details of read are uninteresting).
  66. >  The trouble is of course that Kazimir's unwritten rules are clearly
  67. >  different from other unwritten rules.
  68.  
  69. I believe that my unwritten rules agree with what other UNIX/POSIX programmers
  70. also believe about the read() function, the same way that those Fortran 66
  71. programmers held a consensus about the reversed DO loop or large array passing.
  72.  
  73. >  I think one of the most essential things to understand in programming
  74. >  is the importance of abstracting specifications from implementation.
  75. >  Comments like the above (unwritten rules) one show that there is a
  76. >  long way to go!
  77.  
  78. My reasoning was not based on any implementation. I actually got the idea of
  79. these unwritten rules from your posting about language implementations which
  80. give a meaning to certain behaviors that are not standard simply to reflect
  81. practice among programmers (like the Fortran 66 unwritten 'at least once'
  82. semantics for a reversed DO loop that you mentioned). In this case, the
  83. unwritten rule is not that you may misrepresent the buffer size, but rather the
  84. opposite. Conduct a survey of UNIX programmers, and see. :) This empirical
  85. notion about unwritten rules is thanks to you, not me! I abstract to the safer
  86. alternative regardless of what anyone thinks.
  87.  
  88. Of course, this heuristic doesn't work all the time. It failed in the case of
  89. select(). How was I to guess that the function will modify the timeval
  90. structure, when the program worked properly on two other systems? There is
  91. clearly another ``unwritten rule'' about the behavior of select(), but in this
  92. case I unconsciously believed in it. After running into the problem, I no
  93. longer believe in the ``unwritten rule'' but in the safest rule, and no longer
  94. count on the contents of the timeval structure being preserved after a select()
  95. call, regardless of the implementation. In the case of read(), my intuition has
  96. always been to specify the actual buffer size. It just so happens that in this
  97. case the weaker assumption is in agreement with the common belief, whereas in
  98. the case of select() the stronger assumption is the common belief.
  99.  
  100. The difference between safest assumptions and unwritten rules is that the
  101. latter are subjective, because they are determined by the concensus of
  102. community of programmers, whereas the former are not subjective because they
  103. are based on rational reasoning.
  104.  
  105. Are you familiar with ``Pascal's Wager''? It is a way to decide between
  106. alternate hypotheses. You draw a table like this:
  107.  
  108.  
  109.         call read() with        exaggerate the buffer
  110.         correct buffer size        the buffer size to read()
  111.  
  112. lying about    You are OK            You are OK
  113. buffer is OK
  114.  
  115. lying about    You are OK            You could be screwed
  116. buffer is
  117. *NOT* OK.
  118.  
  119.  
  120. I'm not about to pick the lower right hand corner, just because I can interpret
  121. the vague spec in a way that could justify a belief in the corresponding
  122. hypothesis.
  123.  
  124. Pascal used this method of inference to justify a belief in God, incidentally,
  125. hence the name. :)
  126.  
  127. It has nothing to do with my belief about what the implementations are like, or
  128. what the unwritten rules are.
  129. -- 
  130.  
  131.